home *** CD-ROM | disk | FTP | other *** search
/ Monster Media 1996 #15 / Monster Media Number 15 (Monster Media)(July 1996).ISO / wildcat / vm100a_b.zip / VMFILES.DAT / VIASERV.DOC < prev    next >
Text File  |  1996-05-06  |  15KB  |  415 lines
  1.   ───────────────────────────────────────────────────────────────────────
  2.                       H E L P   I N F O R M A T I O N
  3.                             Revised: 05/06/96
  4.   ───────────────────────────────────────────────────────────────────────
  5.  
  6.   This system uses a special command interpreter (called ViaSERV!) which
  7.   allows you to send specially formatted netmail messages addressed to the
  8.   appropriate server and upon validation of the command(s), perform
  9.   changes to your configuration.  This process is completely automatic and
  10.   requires little (if any) intervention on the local system administrators
  11.   part.
  12.  
  13.  
  14.   COMMAND SERVER
  15.   ──────────────
  16.  
  17.   Presently two server names are used:
  18.  
  19.                      ECHOSERV - Echomail conferences
  20.                      ARCSERV  - Filebone conferences
  21.  
  22.   Selecting the apropriate server name only affects the performance of the
  23.   SUBSCRIBE and UNSUBSCRIBE commands.  For example, using ECHOSERV in the
  24.   To: name field dictates that using either the SUB/UNSUB commands will
  25.   only affect the echomail conferences.  Likewise, using ARCSERV will only
  26.   affect your filebone or TIC file areas.
  27.  
  28.   Since a common command set is used, you may take advantage of the various
  29.   SET and GET commands (such as changing passwords, compression methods
  30.   etc) regardless of which server the message is actually addressed to.
  31.   This greatly simplies things by preventing you from having to learn a
  32.   second set of commands.
  33.  
  34.  
  35.   SECURITY
  36.   ────────
  37.  
  38.   Due to the power of this capability, ViaSERV! employs built-in security
  39.   methods preventing unauthorized systems from gaining access and altering
  40.   your configuration.  Any attempts to activate options you don't have
  41.   sufficient access to will produce a response message back to your system
  42.   informing you of this.
  43.  
  44.   All security level definitions and configuration is handled at the
  45.   uplinks system, so any changes with regard to security must be made
  46.   directly by the uplinks SysOp.  If you have any questions in this regard,
  47.   you should contact him/her directly.
  48.  
  49.  
  50.   RESPONSE MESSAGE
  51.   ────────────────
  52.  
  53.   For every message you send, you will receive a response back telling you
  54.   what was the outcome of the commands used.  Not only is this useful to
  55.   verify that changes took place, but issuing the various GET STATUS, GET
  56.   QUERY commands, you can see what are the conferences selected, your
  57.   configuration and so on.
  58.  
  59.  
  60.   SPECIALLY FORMATTED NETMAIL MESSAGE
  61.   ───────────────────────────────────
  62.  
  63.   When defining this message there's two distinct sections to configure.
  64.   The message header (to/from addressing etc) and the message body.
  65.  
  66.   The message header selects the appropriate command server (ECHOSERV or
  67.   ARCSERV) as well as the associated AKA address. The message body is
  68.   where all the commands are placed.
  69.  
  70.   As mentioned above, selecting the To: name as ECHOSERV means using the
  71.   SUB/UNSUB commands only affect your echomail areas and the name ARCSERV
  72.   will only change your filebone or TIC file areas.
  73.  
  74.  
  75.   MESSAGE HEADER
  76.   ──────────────
  77.  
  78.   When defining the message header, the 5 basic sections are described
  79.   below.
  80.  
  81.   To: address    The netmail message should be addressed to your uplinks
  82.                  primary or any one of his AKAs (alternate addresses).
  83.  
  84.   To: name       Either ECHOSERV or ARCSERV.
  85.  
  86.   From: address  The FROM: address of the message should be your address
  87.                  that has access to the related functions this request
  88.                  is being configured for.  In other words, you should use
  89.                  your correct AKA address relative to the network you're
  90.                  requesting conferences for.  You wouldn't want to use
  91.                  your Fido address for conferences within WSNET, instead
  92.                  you would use your WSNET address.
  93.  
  94.   From: name     Normally you would use your regular name here.  This
  95.                  field is not used except for display purposes.
  96.  
  97.   Subject line   This is one of the most crucial definitions because here
  98.                  is where you specify your password that will enable the
  99.                  use of the ViaSERV! commands.
  100.  
  101.  
  102.   MESSAGE BODY
  103.   ────────────
  104.  
  105.   The message body portion of the Netmail message is where all the 'action'
  106.   takes place.  Here you could use the various SET and GET type commands to
  107.   perform the desired action.
  108.  
  109.   You should only use one SET or GET command per line along with it's
  110.   apropriate parameters.  If you'd like to enter multiple commands, you may
  111.   do so by using multiple lines (one command per line).
  112.  
  113.   Blank lines, that is, a line with no text on it as well as lines that
  114.   start off with a ';' or '#' character (in position 1) will be ignored.
  115.   You might structure your message this way to provide better formatting
  116.   for easy recognition.
  117.  
  118.  
  119.   AVAILABLE COMMANDS
  120.   ──────────────────
  121.  
  122.   As previously mentioned, the commands used by ViaSERV! are:
  123.  
  124.   SUB   - (or SUBSCRIBE) refers to the activation of a echomail conference
  125.           or filebone area allowing the flow of mail/files for that area.
  126.  
  127.   UNSUB - (or UNSUBSCRIBE) performs the exact opposite action.  Disables
  128.           the flow of mail/files for that area.
  129.  
  130.   GET   - Refers to having ViaSERV! collect information and return the
  131.           results in the response message.
  132.  
  133.   SET   - Used to toggle the various settings either on, off or to some
  134.           valid value.
  135.  
  136.   Each of these commands requires the use of parameters in order for it to
  137.   function properly.  The format of these parameters will vary depending on
  138.   it's usage and it explained below.
  139.  
  140.  
  141.   SET COMMANDS
  142.   ────────────
  143.  
  144.   SET ARCFORMAT <format>
  145.  
  146.   This command allows you to define the compression format that should be
  147.   used when echomail is bundled up for your system.  A common usage might
  148.   be:
  149.  
  150.                              SET ARCFORMAT ZIP
  151.  
  152.   The compression method (in this case ZIP) must be one of the available
  153.   formats supported by the system.  Selecting an invalid format results in
  154.   a listing of available formats in the response message.
  155.  
  156.  
  157.   SET ECHOACTIVE <YES|NO>
  158.  
  159.   This command allows you to temporarily turn on or off the flow of
  160.   echomail.  For example:
  161.  
  162.                               SET ECHOACTIVE NO
  163.  
  164.   would turn off the flow of mail while replacing the NO with YES would
  165.   turn it back on again.  This option is handy should you be away from your
  166.   system for an extended period of time.  Once you return, reactivating
  167.   your system via the SET ECHOACTIVE YES command would start the flow of
  168.   mail again.
  169.  
  170.  
  171.   SET FILEACTIVE <YES|NO>
  172.  
  173.   This command functions exactly the same as SET ECHOACTIVE except that it
  174.   controls the flow of TIC files.
  175.  
  176.  
  177.   SET SERVPSWD <pswd>
  178.  
  179.   This command allows you to specify the password that should be used on
  180.   the subject line of the message addressed to ECHOSERV or ARCSERV.  A
  181.   common usage might be:
  182.  
  183.                               SET SERVPSWD happy
  184.  
  185.   This would change the current password to 'happy'.  You should note that
  186.   while the password is in lowercase, when passwords are actually checked,
  187.   upper/lower case becomes insignificant.
  188.  
  189.  
  190.   SET SESSPSWD <pswd>
  191.  
  192.   This command allows you to define what your session password should be
  193.   when calling this system.
  194.  
  195.                               SET SESSPSWD mail
  196.  
  197.   This password is used by the mailer when a remote system is calling and a
  198.   secure session is required.
  199.  
  200.  
  201.   SET INPKTPSWD <pswd>
  202.  
  203.   This command allows you to specify what should be expected by your uplink
  204.   system at the password on echomail PKT files that your system sends to
  205.   them.  A typical usage might be:
  206.  
  207.                              SET INPKTPSWD nice
  208.  
  209.   Once a password is established, all echomail from your system MUST have
  210.   this password on it, otherwise it will be rejected.  If you would like to
  211.   remove the password, simply use:
  212.  
  213.                              SET INPKTPSWD
  214.  
  215.   You should otice that no password has been defined.
  216.  
  217.  
  218.   SET OUTPKTPSWD <pswd>
  219.  
  220.   This command functions nearly identically to it's counter part INPKTPSWD
  221.   with the exception being that this is the password that will be put on
  222.   echomail PKT files set TO your system from your uplink.  For example:
  223.  
  224.                            SET OUTPKTPSWD good
  225.  
  226.   Upon setting this password, you should to verify that this password
  227.   matches what you have configured for your uplinks system in your echomail
  228.   tosser.  The same method applies to removing the password as with the
  229.   INPKTPSWD command.
  230.  
  231.  
  232.   SET PKTFORMAT <format>
  233.  
  234.   This command allows you to specify the format used when echomail is added
  235.   to PKT files destined for your system.  Current types are TYPE2, TYPE22
  236.   and TYPE2+.  A common usage might be:
  237.  
  238.                            SET PKTFORMAT TYPE2+
  239.  
  240.   Normally this option would be set to TYPE2+, however you may change it
  241.   as needed.  A special note for 'point' systems.  If you're a point off of
  242.   your boss node, you will not be able to select TYPE2 as your PKT type.
  243.   This is due in part to the inability of a TYPE2 PKT to correctly support
  244.   a point address.  In that case, simply use TYPE22 or TYPE2+.
  245.  
  246.  
  247.   SET UNCOMPSIZE <bytes>
  248.  
  249.   This command allows you to specify the total uncompressed bytes of
  250.   echomail messages is allowable before a new archive gets created.  Common
  251.   usage might be:
  252.  
  253.                           SET UNCOMPSIZE 2000000
  254.  
  255.   The value (in bytes) should be a conservative number taking into account
  256.   the amount of free disk space on your system and the 'affordability' of
  257.   losing a archive should it become corrupted.  A common value here would
  258.   be 2,000,000.
  259.  
  260.  
  261.   SYSTEM INFORMATION
  262.   ──────────────────
  263.   The following SET commands control the user specific information about
  264.   your system.
  265.  
  266.             SET SYSOPNAME <name>          SET BBSNAME <name>
  267.             SET MAILADDR1 <part 1>        SET MAILADDR2 <part 2>
  268.             SET CITY <name>               SET STATE <state>
  269.             SET ZIPCODE <zipcode>         SET VOICEPHONE <number>
  270.             SET DATAPHONE <number>
  271.  
  272.   As with all the SET commands, these require the same 'third' parameter
  273.   which replaces the existing information by what is specified.
  274.  
  275.  
  276.   GET COMMANDS
  277.   ────────────
  278.  
  279.   GET HELP
  280.  
  281.   This command will cause the entire contents of the information to be sent
  282.   to you in the response mesage.  A common usage would be:
  283.  
  284.                               GET HELP
  285.  
  286.   You might consider using this command if you have trouble obtaining the
  287.   information and/or results you're looking for.
  288.  
  289.  
  290.   GET LIST
  291.  
  292.   This command will create a complete list of all the echomail conferences
  293.   (or filebone areas) you currently have access to.  A common usage would
  294.   be:
  295.  
  296.                                GET LIST
  297.  
  298.   This list will be sent back to you in the response message.  Depending on
  299.   your uplinks configuration, this list could be quite large, so the
  300.   response message(s) will be split accordingly.
  301.  
  302.  
  303.   GET QUERY
  304.  
  305.   This command will create a list of all the echomail conferences (or
  306.   filebone areas) your system is currently selected for.  A common usage
  307.   would be:
  308.  
  309.                                 GET QUERY
  310.  
  311.   This list will then be sent back to you in the response message.  Since
  312.   this list could be quite large, the response message(s) will be split
  313.   accordingly.
  314.  
  315.  
  316.   GET UNLINKED
  317.  
  318.   This command is the counterpart to the GET QUERY command.  Instead of
  319.   showing you all the selected areas, it will show you all of the echomail
  320.   areas (or filebone areas) you have access to excluding the ones you're
  321.   allready selected for.  A common usage would be:
  322.  
  323.                                 GET UNLINKED
  324.  
  325.   This command is handy when you would like a list of areas that are still
  326.   available for you to 'turn on'.
  327.  
  328.  
  329.   GET STATUS
  330.  
  331.   This command will create a list of all the current settings your system
  332.   is configured for and send it back to you in the response message.  A
  333.   common usage would be:
  334.  
  335.                                 GET STATUS
  336.  
  337.   This command is handy when you'd like to review your current
  338.   configuration prior to making changes.
  339.  
  340.  
  341.   GET RESCAN <conf> <num>
  342.  
  343.   This command allows you to extract the last <num> messages from the
  344.   specified conference <conf> on your uplinks systems.  A typical usage
  345.   might be:
  346.  
  347.                           GET RESCAN FOR-SALE 100
  348.  
  349.   In the above example, the last 100 messages from the FOR-SALE echomail
  350.   conference would be extracted and packed up for your system.  Since this
  351.   option only applies to echomail messages, you will not able to use this
  352.   command if the message is sent to ARCSERV.  There is one additional
  353.   limitation of this command.
  354.  
  355.   Since this command is meant to extract messages from a particular message
  356.   base, if your uplinks system only carried the specified conference as a
  357.   'pass-thru', attempting to use this command will result in no messages
  358.   sent back to your system.  This is because a pass-thru conference doesn't
  359.   have an associated message base upon which to extract messages from.
  360.  
  361.  
  362.   GET CONTACT
  363.  
  364.   This command will retrieve the contact information from your uplinks
  365.   system and send it back to you in the response message.  A common usage
  366.   would be:
  367.  
  368.                                 GET CONTACT
  369.  
  370.   Since this information normally contains your uplinks phone number and
  371.   mailing address, this information could be useful should you need to
  372.   contact him/her to discuss certain issues.
  373.  
  374.  
  375.  
  376.   SIGNALING THE END OF COMMANDS
  377.   ─────────────────────────────
  378.  
  379.   A special group of characters called a tear line should be placed after
  380.   the last command to signal that no more commands should be interpreted.
  381.  
  382.   This tear line consists of three dashes (---) together starting on column
  383.   1 of a blank line. Although the tear line is not required, it should be
  384.   there as a matter of practice.  This is done in cause you'd like to
  385.   enter some text after the commands and not have them interpreted.
  386.  
  387.  
  388.   SAMPLE MESSAGE
  389.   ──────────────
  390.  
  391.   Shown below is a sample message.
  392.  
  393.  
  394.   [1]     15 Feb 96  19:24:32                                      Cost: 0
  395.   By: Joe Martin, The ViaSoft Support BBS (92:105/8)
  396.   To: ECHOSERV, (92:105/0)
  397.   Re: Password
  398.   St: Kill  Del/sent Local
  399.   ─────────────────────────────────────────────────────────────────────────
  400.   SUB FOR-SALE
  401.   UNSUB WILDCAT
  402.  
  403.   GET RESCAN FOR-SALE 50
  404.   GET RESCAN GAMING ALL
  405.   GET RESCAN WOODWORKING 100
  406.  
  407.   GET QUERY
  408.   SET UNCOMPSIZE 2000000
  409.   SET ARCFORMAT ARJ
  410.  
  411.   ---
  412.   Any text below this (tear) line will be ignored.
  413.  
  414.                                -End of Help-
  415.